Skip to content
This repository was archived by the owner on Jul 13, 2020. It is now read-only.

New Readme for 0.50 #492

Merged
merged 1 commit into from
Jun 20, 2016
Merged

New Readme for 0.50 #492

merged 1 commit into from
Jun 20, 2016

Conversation

probins
Copy link
Contributor

@probins probins commented Jun 20, 2016

OK, here's my first stab at this, as discussed in #491. Comments of course welcome. I've removed all the links to other docs until these are (re)written, and all the usage examples until these actually work :-)

Not sure whether you want to keep the existing copyright; neither Luke nor Addy has contributed anything for years. 'Copyright contributors' perhaps?

It might be a good idea to mark 1.0 as deprecated - perhaps rename it too? - and change the master Readme to point to this branch rather than 1.0.

@probins
Copy link
Contributor Author

probins commented Jun 20, 2016

just added a further polyfill needed, for Symbol.iterator

@probins
Copy link
Contributor Author

probins commented Jun 20, 2016

might be a good idea to disable travis on this branch for the moment


The final specification, though, only defines the [language-specific semantics of modules](http://www.ecma-international.org/ecma-262/6.0/#sec-modules), leaving implementations of the loading of those modules to separate specifications. The dynamic configurable loader is being specified at the [WhatWG loader spec](https://whatwg.github.io/loader/), and from version 0.50 this polyfill implements that.

Support for static loading of modules from HTML using `<script type="module">` tags has also been added to the [WhatWG HTML specification](https://html.spec.whatwg.org/multipage/scripting.html#the-script-element). This adapts the existing script-loading mechanism to include the loading of 'module scripts' together with all the other modules on which those module scripts depend. Unlike the WhatWG loader, however, this is not configurable, and has no connection with the loading pipeline defined there and implemented in this polyfill.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unlike the WhatWG loader, however, this is not configurable, and has no connection with the loading pipeline defined there and implemented in this polyfill.

This isn't quite right. The point is for the WhatWG loader to share the same module registry as the <script type="module"> tag. And also for the WhatWG loader resolution hooks to affect the loading of the module tag as well. Perhaps @caridy can help confirm this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where have you seen the term module scripts used? Module tag is preferable I think.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the HTML spec I link to refers to 'classic scripts' and 'module scripts'

@probins
Copy link
Contributor Author

probins commented Jun 20, 2016

Put the contributors in alpha sequence, which means G Bedford rightly comes at the top :-)

@guybedford guybedford merged commit 2977429 into ModuleLoader:0.50 Jun 20, 2016
@guybedford
Copy link
Member

👍

@probins probins deleted the 0.50-readme branch June 20, 2016 18:48
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants